Static code analysis in multi-threaded environments

Who can understand his errors? Cleanse thou me from secret faults. Preface The notion that software might contain errors dates back to the famous annotations of Lady Ada Lovelace to the description of the Analytical Engine designed by Charles Babbage[36] where she states: " Granted that the actual mechanism [of the Analytic Engine] is unerring in its processes, the cards may give it wrong orders. This is unquestionably the case; but there is much less chance of error, and likewise far less expenditure of time and labour, where operations only, and the distribution of these operations, have to be made out, than where explicit numerical results are to be attained. " Despite Lady Lovelace's assessment, errors in software (i.e. today's equivalent of cards that give wrong orders) have become a predominant concern in software development and software engineering. Nowadays, the vast majority of software engineers and hackers alike believes that all sufficiently complex software has bugs. Solutions that have been proposed to uncover bugs reach from testing on the one hand to rigorous formal proofs of correctness on the other hand. In this work we follow an intermediate approach that tries to use sound and conservative static code analysis techniques to avoid certain classes of bugs without having to conduct a full blown formal proof of correctness. The methods developed in this work are tailored to concurrent systems where global data is shared between all threads. While this requirement is not strictly necessary for the soundness of the analysis we shall see that it greatly increases the accuracy. In this context accuracy refers to the likelihood that a problem reported by the analysis is caused by an actual bug in the software and not by an inadequacy of the analysis methods. The usefulness of the methods presented will be supported by several case studies conducted on real life software systems of significant size. Nevertheless, I am convinced that in software engineering there is no Holy Grail that software can gain eternal bug free life from. As a corollary this Holy Grail cannot be expected to be found in this work. Thus, readers are encouraged to use the methods described in this work to supplement but not to replace existing bug prevention and software quality techniques. 1 2 Acknowledgments This work has been developed at the Institute of Applied Information Processing at the University of Ulm. I would like to express …